Governments and businesses are increasingly interested in issuing virtual ID cards to citizens, customers and employees. The virtual ID cards may be provided on mobile phones, or other similar personal computing device, and displayed using an app running on the device. In some cases, what verifying authorities need to know is not just the identity of the person before them, but instead, other information about the person such as the age of the person or the state of the licenses associated with that person (e.g., revoked, active, etc.). For example, a license holder may present their driver's license to service provider to prove the age of the license holder in connection with purchasing liquor even though the purchase of liquor is unrelated to the issuance by a state of the driver's license. Generally, a state issued driver's license is considered proof of identity and/or age in a number of situations unrelated to driving an automobile. The same may be true, perhaps to a lesser extent, to other types of licenses/credentials issued by government or other authorities.
A relying party that is verifying credentials of a license holder may use a relying party device to read/confirm information provided by a license holder device of the license holder. However, it is desirable that the license holder not release information to an unauthorized relying party or to a malicious actor fraudulently posing as a relying party. This may be addressed by having the relying party use a verifying device secret (VDS) to identify and authenticate the relying party device. For example, the VDS could be a private key of a public/private key pair where the public key for the particular relying party is provided in a PKI digital certificate. In such a case, the license holder could evaluate digitally signed data from the relying party device to confirm authenticity of the relying party. Note that there are many mutual authentication protocols, such as Seos, Seos AKE, OPACITY, PACE, EVM, etc., that could use a VDS of the relying party. Note also that, it some instances, it may also be advantageous for the license holder to use his or her own device secret to verify authenticity. Of course, it is not necessary for the license holder to use the same device secret mechanism as the relying party.
In the case of a relying party using a dedicated device, it is possible to implement some form of secure key storage to protect the VDS from being extracted by an attacker, copied etc. Secure key storage could use secure elements (SEs), Trusted Execution Environments (TEES), etc., which may be generally referred to as Secure Access Modules (SAMs). However, in instances where it is desirable to use a programmed off-the-shelf device for the relying party device, such as a smartphone, it may be more difficult to provide SAM functionality for the relying party device. Some smartphone models provide only limited or costly access to their secure element, such as a UICC (SIM) or an embedded secure element. In some cases, managing the VDS on such devices requires costly integration with trusted service managers or contracts being setup to buy space on such secure elements from an SE issuer, such as a mobile network operator in the case of a SIM or a smartphone manufacturer in the case of the embedded secure element. Another possibility is the use of the TEE technology, which may be easier to manage, but is only present on certain smartphone models (e.g., Android) and may not provide the same level of protection as an SE and does not provide certifiable (Common Criteria or FISP) protection. Similarly, in off-the-shelf smartphones having slots, an SE such as a secure microSD may be used, but many smartphone models do not have slots.
Accordingly, it is Desirable to Provide VDS Functionality in Instances where an Off-the-Shelf Smartphone is Used as a Verifying Device.